„ S'Jl.JUL 

95943-6002 



NAVAL POSTGRADUATE SCHOOL 



A DATABASE DESIGN FOR A UNIT STATUS 
REPORTING SYSTEM 

by 

Ann Jacoby Stebbins 
March 1987 

Thesis Advisor: Y. K. Mortagy 

Approved for public release; distribution is unlimited. 



Monterey, California 




THESIS 



T 234392 




REPORT DOCUMENTATION PAGE 



unc lass ified 

j - ~ 'a 



•3 RE?OR T security ClASSiFiCATiON 

unclassified 



’b RESTRICTIVE MARKINGS 



2a SECuR Ty Classification authority 



2d DEClASSiFiCATiON / OOWNGRAOiNG SCHEDULE 



3 distribution / availability of report 
Approved for public release; 
distribution is unlimited. 



i PERFORMING ORGANIZATION REPORT NUMBER(S) 



5 MONITORING ORGANIZATION REPORT NUV3£R(S) 



6a NAME OF PERFORMING ORGANIZATION 

Naval Postgraduate School 



6b OFFICE SYMBOL 
(If applicable) 

54 



7a NAME OF MONITORING ORGANIZATION 

Naval Postgraduate School 



6< ADDRESS tC/ry Staff. indtIPCod*) 

Monterey, California 93943-5000 



7b AOORESS (Cry. Staff, »nd HP Code) 

Monterey, California 93943-5000 



9a NAME OF FUNOiNG / SPONSORING 
ORGANIZATION 



8b OFFICE SYMBOL 
(If applicable) 



9 PROCUREMENT INSTRUMENT IDE N TiF iCA T ION NUMBER 



8c ADDRESS (City, State, and /IP Code) 



10 SOURCE OF FUNDING NUMBERS 



PROGRAM 


PROJECT 


task 


WORK UNIT 


ELEMENT NO 


NO 


NO 


ACCESS. ON NO 



' t ; T l E (include Security Claudication) 

SYSTEM 



A DATABASE DESIGN FOR A UNIT STATUS REPORTING 



2 PERSONAL AUTHOR(S) 



Stebbins, Ann Jacoby 



1 'YPE OF REPORI 

laster ! s Thesis 


13b r-ME COVERED 
FROM TO 


14 DATE OF REPOR 

1987 Marc 


jT ( Year Month Day) 



'5 PAGE COoNT 



164 



6 Supplementary notation 



• - 


COSATi CODES 


18 SUBJECT TERMS (Continue on reverie d neceuary and identify by block number ) 


f ElD 


GROUP 


SUB-GROUP 


unit status reporting system (USR); database; 









semantic database model (SDM) 



9 ABSTRACT (Continue on reverie d neceuary and identify by block number) 



This thesis advances the hypothesis that utilization of a database manage- 
ment systems (DBMS) will lead to improved accuracy and decrease the amount 
of time spent on the preparation of the U.S. Army’s Unit Status Report 
(USR) . This study developed data flow diagrams of the proposed USR system^ 
along with a supporting passive data dictionary. A Semantic Database' 

Model (SDM) schema for the proposed USR system is also presented. This 
thesis concludes that the proposed database design for the USR system be 
implemented using a standard (Army-wide) DBMS. 



20 D $'R' BUT iON/AVAILABILITY 
OXNCLASSIFIEDAJNL'MITED 



OF ABSTRACT 
□ SAME AS RPT 



□ DTiC USERS 



21 ABSTRACT SECURITY CLASSIFICATION 


unclassified 




22b TELEPHONE (include Area Code) 


22c OFFICE SYMBOL 


1408') 646- 2360 


5 4M 



22a NAME OF RESPONSIBLE 1 NO 1 V 1 OUAL 

Y.K. MortaLjv 



DD FORM 1473, 84 mar 



83 APR edition may be used until exhausted 
All other editions are obsolete 

1 



SECURITY CLASSIFICATION OF -hiS PAGE 

unclassified 



Approved for public release; distribution is unlimited. 



A Database Design for a 
Unit Status Reporting System 



by 

Ann Jacoby Stebbins 

Captain, Transportation Corps, U.S. Army 
B.S. Ed. , Indiana University of Pennsylvania, 1978 

Submitted in partial fulfillment of the 
requirements for the degree of 

MASTER OF SCIENCE IN INFORMATION SYSTEMS 

from the 



NAVAL POSTGRADUATE SCHOOL 

March 1987 



ABSTRACT 



This thesis advances the hypothesis that utilization of 
a database management system (DBMS) will lead to improved 
accuracy, and decrease the amount of time spent on the 
preparation of the U.S. Army’s Unit Status Report (USR). 
This study developed data flow diagrams of the proposed USR 
system, along with a supporting passive data dictionary. A 
Semantic Database Model (SDM) schema for the proposed USR 
system is also presented. This thesis concludes that the 
proposed database design for the USR system be implemented 
using a standard (Army-wide) DBMS. 



f- 



3 






/ 



■ r 
'5 



TABLE OF CONTENTS 

INTRODUCTION 7 

A. GENERAL 7 

B. RESEARCH PLAN 9 

1 . Objectives 9 

2. Research Hypothesis 10 

3. Research Questions 10 

4. Research Methodology 10 

C. THESIS ISSUES 11 

1. Scope of the Study 11 

2. Assumptions 11 

3. Limitations 12 

D. ORGANIZATION 12 

II. BACKGROUND 13 

A. INTRODUCTION 13 

B. GENERAL DESCRIPTION OF THE REPORT 13 

C. DESCRIPTION OF REPORT PREPARATION 14 

1 . General 14 

2. C-Rating Definitions 16 

3. Personnel Status 17 

4 . Equipment On-Hand Status 19 

5. Equipment Readiness 21 

6. Training Status 1 23 

7. Overall Unit C-Rating 25 

D. REPORTING REQUIREMENTS 26 

1 . Frequency and Type of Reports 26 



4 



2. Types of Units 27 

3. Reporting Channels 28 

E. SUMMARY 28 

III. OVERVIEW OF THE THEORY 30 

A. INTRODUCTION 30 

B. DATABASE SYSTEMS 30 

1. Definitions 30 

2. Components of a Database System 31 

3. Advantages of a Database System 33 

4 . Architecture of Database Systems 34 

5. Database Development Stages 37 

C. DATA MODELS 38 

1. Definition 38 

2. Purpose and Objectives of Data Models 38 

3. Main Components of a Data Model 39 

4. The Semantic Database Model 41 

D. STRUCTURED ANALYSIS 44 

1. Definitions 44 

2. Goals of Structured Analysis 45 

3. The System Life Cycle 45 

4 . Structured Tools 46 

E. SUMMARY 51 

IV DEVELOPMENT OF THE DATABASE MODEL 52 

A. INTRODUCTION 52 

B. SPECIFYING THE REQUIREMENTS 52 

1. Problem Definition and Feasibility 

Assessment 53 



5 



2. Specify Detailed Requirements 54 

C. EVALUATING THE ALTERNATIVES 54 

1 . Specifying Alternatives 55 

2. Selecting One Alternative 55 

D. DESIGNING THE DATABASE MODEL 56 

1. Define the Logical Database Structure 56 

2. Define the Physical Database Structure -- 57 

E. USER INTERFACE 57 

F. SUMMARY 58 

V. CONCLUSIONS AND RECOMMENDATIONS 59 

A. CONCLUSIONS 59 

B. RECOMMENDATIONS 60 

APPENDIX A: ARMY REGULATION 220-1 61 

APPENDIX B: FEASIBILITY ASSESSMENT 88 

APPENDIX C: QUESTIONNAIRE 109 

APPENDIX D: DATA FLOW DIAGRAMS 110 

APPENDIX E: DATA DICTIONARY 130 

APPENDIX F: SDM SCHEMA 149 

APPENDIX G: USER VIEWS 157 

APPENDIX H: BACHMAN DIAGRAM 159 

APPENDIX I: HIERARCHY DIAGRAM 160 

LIST OF REFERENCES 161 

BIBLIOGRAPHY ' 162 

INITIAL DISTRIBUTION LIST 163 



6 



INTRODUCTION 



I . 



A. GENERAL 

The idea for this thesis originated during a meeting 
with the commander of the 274th Supply Support Detachment of 
the 7th Infantry Division (Light), Fort Ord. The purpose of 
the meeting was to discuss potential projects involving the 
use of computers. The outcome of the discussion was a 
perceived need to automate certain unit record-keeping and 
reporting requirements, specifically the Unit Status 
Reporting System. 

Maintaining an accurate and up to date evaluation of 
every unit's readiness to deploy has a high priority in the 
United States Army. The Army’s Unit Status Reporting System 
has been established, under Army Regulation 220-1, to 
satisfy this need. Objectives of the reporting system are 
to provide: 

1. The current status of U.S. Army units to national 
command authorities (NCA’s), the Organization of the 
Joint Chiefs of Staff (OJCS), Headquarters, 

Department of the Army (HQDA) , and all levels of the 
Army chain of command. 

2. Indicators to HQDA that-- 

a. Portray Army-wide conditions and trends. 

b. Identify factors which degrade unit status. 

c. Identify the difference between personnel and 
equipment assets currently in units and full 
wartime requirements. 

d. Assist in the allocation of resources by HQDA and 
intermediate commands. [Ref. l:p. 3] 
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The USR aids in the determination of a unit’s status by 
comparing selected personnel, equipment and training factors 
to wartime requirements and by using the commander’s overall 
evaluation of the unit. Because the report is not designed 
to measure all aspects of a unit’s readiness status, it 
cannot be used as an isolated tool to assess readiness of a 
unit individually or the Army as a whole. The USR does, 
however, provide a timely, single-source document for 

evaluating key elements of a unit’s status and identifying 
problem areas. 

The Army’s objective with regard to unit status is for 
commanders to develop and maintain their units at the 
highest unit status level possible considering resources 
available to the unit and the unit’s contingency 
requirements. In order to conserve resources, only those 

units needed early on to support contingency plans are 
maintained at the highest resource levels. All other units 
are provided lower levels of resources and thus assigned a 
lower authorized level of organization (ALO). Unit 

commanders are responsible to: 

1. Maintain the highest unit status level possible 
with gi ven resources. 

2. Accurately assess and report unit status. 

3. Distribute unit equipment against mission essential 
requirements (equipment readiness code (ERC)-A) on a 
first priority basis. 

4. Train to the highest level possible with the 
resources that are available. [Ref. l:p.3] 
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Currently, commanders maintain data for the reports and 
prepare them manually. Preparation of the actual report is 
a very time consuming and tedious process. There can be a 
high potential for errors depending on the individual 
commander’s experience in preparing the report. Report 
preparation procedures are difficult and often confusing due 
to the many calculations involved and wide dispersion of 
data used. Reports are usually reviewed at several levels 
of command before being submitted. The entire process of 
gathering the data, preparing, reviewing, and submitting the 



report can end 


up 


requiring 


two 


or three days of the 


commander’s time 


( or 


the time 


of 


some other designated 



officer in the unit). 

B. RESEARCH PLAN 
1 . Ob iectives 

The primary objective of this research is to develop 
a database design for the Unit Status Reporting System. 
Additional objectives are to explore: the unit’s other 

reporting and record-keeping requirements which the database 
might support; how the database will be implemented. 
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2 . Research Hypothesis 

Utilization of a database management system will 
lead to improved accuracy and decrease the amount of time 
spent on the preparation of the Unit Status Report. 

3 . Research Questions 

In pursuing the objectives of the research, the 
following research questions were addressed: 

a. Can a database be designed to support company 
commanders in maintaining all the necessary 
information for determining and reporting their 
unit ’ s status? 

b. Can this database support other unit reporting 
requirements? 

c. What type of data model and data structure should be 
used for this database? 

4 . Research Methodology 

The research methodology utilized for this thesis 
involved a comprehensive review of applicable literature to 
include current Army regulations. Additionally, personal 
and telephone interviews and a brief questionnaire were 
conducted with Army personnel actually involved in the 
preparation and review of the Unit Status Report. 

The 1 iterature utilized in the study was obtained 
through the Naval Postgraduate School library and 
instructors; the U.S.Army Logistics Center, Fort Lee VA; and 
the 7th Infantry Division (Light) G-4 Office, Fort Ord CA . 

Personal interviews were conducted with personnel 
from the 7th Infantry Division (Light) G-4 Office and the 
274th Supply Support Detachment at Fort Ord CA . Telephone 
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interviews were conducted with personnel from tne U.S. Army 
Logistics Center at Fort Lee VA. A brief questionnaire was 
presented to representative units from the 7th Infantry 
Division (Light) at Fort Ord CA. 

C. THESIS ISSUES 

1 . Scope of the Study 

The main thrust of the thesis will be the design of 
the database. Specific emphasis will be on what files will 
be included in the database, what data elements the files 
will contain, and input and output for the database. 
Although the research will concentrate on the requirements 
for the USR, the database design will include other data 
elements required in unit record-keeping. Additionally, the 
design will try to incorporate flexibility for future 
expansion, so that data elements not already included may be 
easily added. 

2 . Assumptions 

This thesis is based on the assumption that using a 
database management system (DBMS) facilitates sharing of 
data, reduces redundancy of data in files, and contributes 
to the maintenance of data integrity. It also assumes that 
using a DBMS allows for rapid retrieval of data and 
increases the amount of information that can be retrieved 
from the data that is stored. Another assumption is that 
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unit-s will have access to microcomputers, but they will not 
have communication capabilities. 

3 . Limitations 

A possible limitation is the fact that the Army, and 
specifically units at Fort Ord have a wide variety of 
computer systems and supporting software, much of which is 
incompatible. Another limitation is the fact that the 
database must comply with the requirements set forth by AR 
220-1 (the regulation which governs the Unit Status 
Reporting System). Additionally, certain portions of the 
Unit Status Report require subjective input, therefore the 
database cannot produce the final product. 

D. ORGANIZATION 

Chapter II provides background information concerning 
the Unit Status Reporting System. 

Chapter III forms the first part of the data analysis 
and findings portion of the thesis. It provides an overview 
of the theory used in the design of the database model. 

Chapter IV forms the second part of the data analysis 
and findings portion of the thesis. It describes the 
development of the database model. 

Chapter V contains the conclusions and recommendations 
which are based on the findings contained in Chapters III 
and IV. 
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II . 



background 



A. INTRODUCTION 

The research material summarized in this chapter forms 
the background for the study of a database model designed to 
simplify the U.S. Army’s Unit Status Reporting System. The 
terms, descriptions, and reference summaries presented in 
this chapter facilitate the understanding of concepts that 
will be explored in the data analysis, findings and 
recommendation segments of this research effort. 

In describing the background of the problem, this 
chapter briefly explains the U.S. Army Unit Status Reporting 
System. The chapter is divided into five parts. After the 
introduction, a general description of the Unit Status 
Report (USR) is outlined. The third part describes 
preparation of the USR, while the fourth describes the unit 
status reporting requirements. Finally, a brief summary 
highlights the overall process. 

B. GENERAL DESCRIPTION OF THE REPORT 

*T* 

The Onit Status Report is designed to assist the unit 
commander in determining their unit’s current status by: 

a. Comparing selected personnel, equipment, and training 
factors to wartime requirements. 

b. Obtaining the commander’s overall assessment of the 
unit . 
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The report provides an indication of the extent, to which 
a unit can perform the mission for which it was designed. 
The Unit Status Report also provides a timely, single-source 
document for assessing key elements of a unit’s status and 
helps the commander identify problem areas of the unit. It 
is important to remember that the report does not measure 
all areas of a unit, therefore it should not be used as the 
sole basis to evaluate unit readiness. 

C. DESCRIPTION OF REPORT PREPARATION 
1 . General 

Preparation of the USR involves evaluating four 
major resource areas within the unit. These areas are: 
personnel, equipment on-hand, equipment readiness, and 
training. Based on the ratings calculated for each area, 
the unit commander determines an overall unit rating. The 
remainder of this section describes how to evaluate and rate 
each area, and determine the overall unit rating. Figure 
2.1 is a sample of DA Form 2715-R, the Unit Status Report. 
It will serve as a reference for this description of report 
preparation . 

Army Regulation 220-1 (included as Appendix A) 
establishes the Unit Status Reporting System. Standard 
rules and procedures used in the preparation of the Unit 
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Status Report, as well as standard aboreviations and terms 
used throughout this chapter may be found in this appendix. 

2 . C-Rating Definitions 

The status of each resource area which is evaluated 



is assigned a numerical C-Rating. A rating of C-l is the 



highest; ratings of C-2, C-3, and C-4 are used to indicate a 



lower unit status (ability to perform designed mission). 

The C-ratings are defined as follows: 

a. The rating C-l is combat ready with no deficiencies. 
The unit has its prescribed levels of wartime 
resources and is trained so that it can be deployed. 
If outside CONUS, it can perform its operational 
contingency mission. 

b. The rating C-2 is combat ready with minor deficien- 

cies. The unit has only minor deficiencies in its 
prescribed levels of wartime resources or training. 
Its ability to perform the wartime mission for which 
it is organized, designed, or tasked is limited. If 
in CONUS, a unit can be deployed, but minor additional 
training or resources are desirable. If outside 

CONUS, it can perform its operational contingency 
mission . 



c. The rating C-3 is combat ready with major deficien- 
cies. The unit has major deficiencies in the 

prescribed levels of wartime resources or training. 
Its ability to perform the wartime mission for which 
it is organized, designed, or tasked is limited. It 
can deploy or execute its operational contingency 
mission at reduced levels, but normally it will first 
be given additional training or resources to increase 
its readiness posture. 

d. The rating C-4 is not combat ready. The unit has 

major deficiencies in its prescribed wartime resources 
or training and its ability to perform the wartime 
mission for which it is organized, designed, or 
tasked. It requires major upgrading prior to 

deployment or employment in combat. However, if 

conditions dictate, the unit might be deployed or 
employed for whatever residual capability it does 
have . 
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e. The rating C-5 is nor combat ready programmed. Due to 
HQDA action or programs, the unit is not ready and 
does not have the prescribed wartime resources or 
cannot perform the wartime mission for which it is 
organized, designed, or tasked. C-4 deployment and 
employment considerations apply. However, if 
conditions dictate, the unit might be deployed or 
employed for whatever residual ability ir does have, 
□nits rated C-5 are restricted to the following: 



a . 



b. 



Units undergoing reorganization 
equipment conversion or transition. 



or 



major 



d. 



e . 



Units placed in cadre status by HQDA. 

Units which are being activated or inactivated. 

Units which are not manned or equipped but are 
required in the wartime force structure. 

Units with primary tasking as training units 
that could be tasked to perform a wartime 
mission. [Ref. l:p. 15-16] 

3 . Personnel Status 

The Unit Status Report provides indicators of a 
unit's personnel status by developing a C-rating that is 
calculated by comparing available strength, available MOS 
(Military Occupational Skill) trained strength, and 

available senior grade strength to wartime requirements. In 
addition, assigned strength and personnel turnover 
information is provided. [Ref. l:p. 9] 

Required strength is determined from the unit’s 
modified table of organization and equipment/table of 

distribution and allowances (MTOE/TDA) --the cadre column for 
cadre units; table of organization and equipment (TOE) Type 
B column for Type B units; and MTOE/TDA required column for 
all other units (see definitions of terms in Appendix A). 
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An assigned strength percentage is determined based 
on a comparison of assigned strength and required strength. 
Assigned strength for Active Component units will equal the 
assigned strength of the latest personnel control number 
(PCN), adjusted to the "as of" date of the Unit Status 
Report. This is done by adding gains and subtracting 
losses which have occurred since the date of the last 
report . 

The available strength percentage is based on a 
comparison of available strength and required strength. 
Available strength is that portion of a unit’s assigned 
strength that is available for deployment and or employment. 
The criteria for determining personnel availability are 
listed in Appendix E of AR 220-1. 

The available MOS trained personnel percentage is 
based on a comparison of available MOS trained personnel and 
required MOS trained personnel. First, the number of MTOE/ 
TDA personnel spaces required by identity (officer, warrant 
officer, and enlisted) and by military occupational 
specialty code (MOSC) is determined. Then the number of 
personn*l>- included in the available strength of the unit by 
identity and MOSC is determined. Trained available 
personnel are matched against the' requirements. 

The available senior grade percentage is determined 
based on a comparison of the number of available 
commissioned officers, warrant officers, noncommissioned 
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officers (grades E5 through E9), and required senior grade 
personnel . 

The personnel turnover percentage is determined by 
comparing the number of personnel reassigned, discharged, or 
separated during the preceding three months of the "as of 
date of the report to assigned strength on the "as of" date. 
This percentage provides an indicator of unit turmoil. 

A personnel rating is calculated by comparing the 
percentages already determined to Tables 3-2 and 3-3 in AR 
220-1. C-rating’s are determined for available strength, 
available MOS trained, and available senior grade strength. 
The unit’s overall personnel C-rating is the lowest of these 
three C-ratings. 

4 . Equipment On-Hand Status 

The Unit Status Report provides indicators of a 
unit’s equipment on-hand (EOH) status by developing a C- 
rating that is calculated by comparing the fill of selected 
equipment to wartime requirements. A rating for all of a 
unit’s reportable equipment and a rating for each pacing 
item is determined. [Ref. l:p. 11] A pacing item is a major 
weapons system, aircraft, or other items of equipment that 
are central to a unit’s ability to perform its assigned 
mission. Pacing items are monitored continuously and 
managed at all levels of command. Not all units will have 
pacing items . 
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Reportable equipment and required quantities are 
determined from the unit's MTOE/TDA. Reportable equipment 
is that equipment which: 

a. For MTOE units, is designated on a unit’s MTOE as 

equipment readiness code "A" (ERC-A), primary weapons 
and equipment. 

b. For TDA units, is listed on a unit's TDA and is 

designated in AR 700-138 or AR 18-25 as DA Form 2406 
(Material Condition Status Report), DA Form 3266-1 
(Army Missile Material Readiness Report), or DA Form 
1352 (Army Aircraft Inventory, Status and Flying Time) 
reportable (until such time as TDA equipment is 

readiness coded). 

c. Has a quantity of 1, or greater, shown in the required 
column of the MTOE/TDA. 

d. Has not been designated as nonreportable/exempt from 
reporting (Appendix G, AR 220-1). [Ref. l:p. 11] 

The quantity of reportable equipment on-hand is 
determined from the unit property book. Substitute items 
will be counted as equipment on-hand for unit status 
reporting purposes if it is a HQDA authorized substitute as 
listed in Appendix H of SB 700-20. 

The unit’s pacing item(s) are determined by checking 
Appendix C of AR 220-1. 

Equipment on-hand (EOH) ratings are computed using 
guidelines provided in AR 220-1 (Tables 3-4 and 3-5, and the 
equipment on-hand C-rating outline). A percent fill is 
calculated for each reportable line item number (LIN) by 
dividing the quantity of equipment on-hand by the quantity 
of equipment required and multiplying by 100 if the number 
of items required under a LIN is 21 or more. The C-rating 
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is then found in A R 220-1, Table 3-4. 



When the number of 



items required under a LIN is 20 or less, the C-rating is 



found using 


Table 3-5 


of AR 


220-1. 


A C-rating 


is then 


determined 


for all 


reportable LIN’ 


s. A C-rating 


is also 


determined 


for the 


unit ’ s 


pacing 


item ( s ) . The 


unit ’ s 


overall ECH 


rating is 


equal 


to the 


lower of these 


ratings 



just determined. 

5 . Equipment Readiness 

The Unit Status Report provides indicators of a 
unit’s equipment readiness and focuses on how well this 
equipment is being maintained. This is done by developing a 
C-rating that is calculated by comparing the combined affect 
of fill and maintenance shortfalls on the status of selected 
equipment to wartime requirements. An equipment readiness 
(ER) rating for all of a unit’s reportable equipment and a 
rating for each pacing item is determined. Equipment 
mission capable (EMC) percentages are developed that 
disregard that portion of the required equipment that is 
short. [Ref. l:p. 13] 

Reportable equipment is determined as that equipment 

which: 

a. For MTOE units, is that portion of the unit status 
reportable equipment identified in paragraph 3-7 of AR 
220-1 that is also designated as maintenance 
reportable in AR 700-138 and AR 18-25. 

b. For TDA units, is listed on a unit’s TDA and is 
designated by AR 700-138 and AR 18-25 as DA Form 2406, 
DA Form 3266-1, or DA Form 1352 reportable. 



21 



c. Has not, been designated as nonreportable/exempt from 
reporting (Appendix G, AR 220-1). 

d. Is not an aircraft assigned to a nonaviation unit 
(unless assigned aircraft is designated as a pacing 
item). [Ref. l:p. 13] 

The ER and EMC statuses are calculated using 
guidelines found in AR 220-1 (Table 3-6, the equipment 
readiness/equipment mission capable C-rating outline in 
Figure 3-7, and the examples found in Figure 3-8). The ER 
percent equals the total available days divided by the total 
required days multiplied by 100. The pacing item ER percent 
equals the pacing item available days/hours divided by the 
pacing item required days/hours multiplied by 100. The EMC 
percent equals the total available days divided by the total 
possible days multiplied by 100. The pacing item EMC 
percent equals the pacing item available days/hours divided 
by the pacing item possible days/hours multiplied by 100. 
The unit’s overall ER rating is equal to the lower of the ER 
C-rating and the pacing item ER C-rating, determined from 
Table 3-6 of AR 220-1. 

Available days/hours are determined from the fully 
mission capable data found on DA Form 2406, DA Form 3266-1, 
and/or DA Form 1352. The ER and EMC percentages will be 
based on the fully mission capable (FMC) status of a unit’s 
reportable equipment averaged over a one-month period. The 
FMC data will be computed beginning the 16th day of the 
prior month and ending the 15th day of the current month. 
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For MTQE units, only ERC'-A equipment will be considered when 
computing the ER rating. 

Required days/hours are determined based on the 
quantity of MTOE/TDA required equipment that is both unit 
status and maintenance reportable, and the number of days/ 
hours in the reporting period. Possible days/hours are 
determined based on the on-hand quantity of MTOE/TDA 
required equipment that is also both unit status and 
maintenance reportable, and the number of days/hours that 
the equipment was on-hand during the reporting period. 

6 . Training Status 

The Unit Status Report provides indicators of a 
unit’s training status by developing a training C-rating. 
The primary purpose of the unit training rating is to show 
the current ability of the unit to perform its assigned 
wartime missions. A secondary purpose of the unit training 
rating is to show resource shortfalls that prevent 
attainment of a training tempo necessary to achieve or 
maintain training objectives. The standard against which 
the unit’s training status is to be measured is its mission 
essential task list (METL). The METL is derived from 
assigned wartime missions and is submitted to, and approved 
by the next higher headquarters in the reporting unit’s 
chain of command. [Ref. l:p. 14] 
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The training rating is subjectively determined by 
the unit's commander, based on first-hand knowledge of the 
unit’s ability to successfully accomplish METL tasks. The 
training rating is partially determined by an estimate of 
the time the unit needs to overcome shortfalls and reach a 
state of being completely trained in METL tasks. The 
commander must base this estimate on personal observations, 
reports, records, inspection results, etc. Additionally, 
commanders should only consider the equipment and personnel 
currently assigned to their unit. 

First, the commander must determine the present 
level of training in their unit by considering such factors 
as: personnel and equipment present for training, leader 

qualifications, the quality of training conducted and the 
availability and quality of training areas, the units 
demonstrated proficiency during recent external evaluations, 
results of individual skill qualification tests, common task 
tests, and physical readiness tests, as well as other 
factors covered in paragraph 3-9. a. of AR 220-1. Based on 
what the commander determines to be the unit’s present level 
of training, an estimate is made of the number of days of 
training necessary for the unit to overcome training 
shortfalls. This number is compared to Table 3-7 in AR 
220-1 to determine a training C-rating. 
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The commander will also evaluate resource 
constraints as to the degree to which they prevent the unit 
from maintaining a training tempo necessary to achieve and 
sustain its desired training objectives. The resource areas 
are: assigned strength shortfalls, special duty 

requirements, availability of funds, availability of 

equipment/materiel, availability of qualified leaders or 
status of aviator training, accessabi 1 i ty of training areas/ 
facilities, availability of fuel, availability of 

ammunition, and availability of time. These areas are 
assessed based on the impact they have on training, either 
insignificant, minor, major, or prohibitive. 

7 . Overall Unit C-Rating 

The overall unit C-rating and mission accomplishment 
estimate (MAE) are the commander’s assessment of the overall 
status of their unit and its ability to accomplish assigned 
wartime missions. MAE is determined only for units with an 
overall rating of C-4 or C-5. [Ref. l:p. 15] 

The commander reviews all of the previously 

determined C-ratings for each area (personnel, equipment on- 
hand, equipment readiness, and training) to determine the 
unit’s overall rating. The lowest of these unit status 
ratings is normally selected, but the commander can 
subjectively upgrade or downgrade the overall rating if it 
does not represent the unit’s true status. If one or more 
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areas are rated as C-5, then the overall rating mast be the 
same. Individual resource areas cannot be subjectively 
changed either. 



D. REPORTING REQUIREMENTS 

In addition to the report preparation instructions, AR 
220-1 specifies other reporting requirements. These 

requirements include: the frequency of report submission, 

the types of reports which are to be submitted, the types of 
units which are required to submit a USR, and the reporting 
channels to be used for USR submission. 

1 . Frequency and Type of Reports 

Army Regulation 220-1 specifies that Unit Status 
Reports are normally submitted the 15th day of each month 
(unless otherwise indicated due to special circumstances). 

There are three types of reports required by AR 
220-1. They are defined as follows: 

a. Regular reports. Provide key status indicators for AA 

level units. These reports are submitted by 

battalions, separate companies, and separate 
detachments . 

b. Cooposite reports. Provide a balanced report that 

comsiders the status of elements that make up a major 
co«bat unit. These reports are submitted by 

divisions, separate brigades, divisional brigades 
operating separately, Special Forces groups, and 
armored cavalry regiments . - 

c. NATO contingency reports. Show the status of units 
measured against the equipment that they would use in 
NATO. These reports are submitted by POMCUS units. 
[Ref. 1 : p. 3-4] 
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This thesis will deal only with regular reports, as 
the other two types are outside the scope of the research. 

Unit Status Reports are required to be maintained on 
file for two years, after which they will be destroyed in 
accordance with AR 380-5. 

2 . Types of Units 

The following type units must prepare and submit 



reports : 

a. Battalions, separate companies, and separate 

detachments or equivalent size units that are parent 
units (identified by an AA level unit identification 
code (UIC)),and are organic to a division, separate 
brigade, Special Forces group, divisional brigade 

operating separately, or armored cavalry regiment. In 
addition, each division, separate brigade, Special 
Forces group, divisional brigade operating separately, 
and armored cavalry regiment will prepare a composite 
report in accordance with paragraphs 3-12 through 3-14 
of AR 220-1. 

b. MTOE units not organic to a division, separate 

brigade, Special Forces group, divisional brigade 

operating separately, or armored cavalry regiment that 
are company size or larger that are parent units 
(identified by an AA level UIC). In addition, parent 
level combat electronic warfare, chemical, medical, 
and intelligence detachments will submit reports. 

c. TDA units that HQDA has designated as reporting units 
in Appendix D of AR 220-1. 

d. MTOE headquarters units whose subordinate units report 
individually will submit a report for the unit 
headquarters only if it is a separate company or 
equivalent size unit. 

e. MTOE and TDA company size or larger units (identified 
by an AA level UIC) subordinate to a USAR training 
division or separate brigade will submit reports. 
Training divisions and separate brigades will forward 
these reports and use the data from them to submit a 
composite report in accordance with paragraphs 3-12 
through 3-14 of AR 220-1. 
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f. General support force units will not report unless 
HQDA so directs. [Ref. l:p. 4] 

3 . Reporting Channels 

Reporting channels for the Unit Status Report are to 
installation or division level, Major U.S. Army Reserve 
Command (MLJSARC), or the State adjutant general, or the 
numbered armies in the continental U.S. (CONUSA). There the 
reports are transposed to machine readable format and then 
forwarded to the major Army commander in the unit’s chain of 
command. The reports are forwarded from there to the OJCS 
and HQDA. Figure 2.2 is a diagram of the unit status 
reporting channels used by Active and Reserve units. 

E . SUMMARY 

This chapter has briefly described the Unit Status 
Reporting System--including report preparation and reporting 
requirements. The current manual preparation of the Unit 
Status Report is the problem identified in this thesis. The 
next chapter is an overview of the theory used to develop 
the data model for the Unit Status Reporting System. 
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Figure 2.2 Unit Status Reporting Channels 
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Ill . OVERVIEW OF THE THEORY 



A. INTRODUCTION 

The Unit Status Reporting System is currently based on a 
traditional, manual record-keeping system. A database 
system is the proposed solution to the problems identified 
in Chapter I . 

The research material summarized in this chapter 
represents an overview of the theory used to develop a 
database model for the Unit Status Reporting System. The 
terms, descriptions, and reference summaries outlined 
facilitate the understanding of concepts used in the data 
analysis, and later in the findings and recommendations of 
this research effort. 

The chapter is divided into five parts. After the 
introduction to the chapter, the second part is an overview 
of database systems. The third presents an overview of data 
models, followed by a review of structured systems analysis. 
The fifth part is a summary. 

B . DATABASE SYSTEMS 

** » 

1 . initions 

A database is defined as a collection of stored 
operational data used by the application systems of some 
particular enterprise. Operational data consists of basic 
entities about which information is to be recorded, and the 
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basic 



relationships linking those basic entities together. 
Operational data is data about the enterprise’s operation 
(i.e., personnel data, training data, equipment data, etc.). 
Therefore operational data does not include the input data, 
the output data, work queues, temporary results, or 
transient information. Input data is information entering 
the system for the first time. It may change or become part 
of the operational data. Output data are messages and 

results coming from the system. It is derived from the 
operational data. [Ref. 2:pp. 9-10] A database is a part of 
a database system. 

A database system is a computerized record-keeping 
system. The user’s files are integrated into a database 
which is processed indirectly by the user’s application 
programs. The overall purpose of a database system is to 
maintain information and allow the user access to the 
information on demand. 

2 . Components of a Database System 

A database system has four major components: data, 

hardware, software, and users. These components interact to 
satisfy the user’s needs. Figure 3.1 illustrates these four 
components of a database system. 

Data is both integrated and shared. Integrated 
means that the database may be thought of as a unification 
of several otherwise distinct data files, with any 
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redundancy among those riles either wholly or partly 
eliminated. Shared means that individual pieces of data in 
the database may be shared among several different users, in 
the sense that each of those users may have access to the 
same piece of data. [Ref. 2:p. 7] 

Hardware consists of the secondary storage devices 
on which the database physically resides, along with the 
associated input and output (I/O) devices, device 
controllers, I/O channels, etc. 

Software provides the interface between the users 
and the database. The software is a database management 
system (DBMS) which handles all requests from the users for 
access to the database. 

Users fall into three broad classes. Application 
programmers are responsible for writing the application 
programs that use the database. End-users interact with the 
system to use the database. The database administrator 
(DBA) is responsible for centralized control of the database 
system . 

3 . Advantages of a Database System 

Database systems provide users with several distinct 
advantages over traditional record-keeping methods. Among 
them are the following: 

a. Compactness--the size of any necessary paper files is 
reduced . 

b. Speed--the computer locates, retrieves, and updates 
data faster than a person can. 
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c. Less drudgery- "mechanical tasks are eliminated 

d. Currency-information is continuously accurate and 
up-to-date . 

e. Centralized control of operational data. 

Of these advantages, centralized control appears to 
be the most significant. Centralized control means having a 
single individual or organization (the DBA) responsible for 
the operational data. Advantages to having this centralized 
control are as follows: 

a. Reduced redundancy-through the integration of files. 

b. Avoid inconsistency-due to reduced redundancy. 

c. Data can be shared--by different users and appli- 
cations . 

d. Standards can be enforced. 

e. Security restrictions can be applied--through access 
control and security checks . 

f. Integrity can be maintained--through reduced redun- 
dancy and checks for accuracy. 

g. Conflicting requirements can be balanced. [Ref. 2: 
pp. 12-15] 

4 . Architecture of Database Systems 

A database system is based on a general three level 

architecture. These levels are an internal level, an 

<■ . 

external level, and a conceptual level. The internal level 
is concerned with the way data is actually stored, or how it 
"looks' 1 to the computer. It is also referred to as the 

physical view, because it describes how data is physically 
arranged and how it is allocated to files. The external 
level is concerned with the way data is viewed by the 
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individual users (i.e. , the orderly room, training section, 
supply section, or maintenance section of a unit). It is 
also referred to as a logical view, because it describes how 
the data would be presented to the different users. The 
conceptual level is concerned with a community user view, or 
the total database content. It is also referred to as the 
complete logical view of the data. All three views must be 
defined before the database can be processed. Figure 3.2 
illustrates the difference between logical and physical 
views . 

The external and conceptual levels deal with views. 
A view may be looked at as a "virtual" table. It does not 
exist in its own right, but it appears to the user as if it 
does. A view is not supported by its own physically 

separately stored data, but rather it is defined in terms of 
other stored tables. So, a view is a "window" into a real 
table. Also, it is dynamic in that changes to the real 
table it is based on will automatically be visible to the 
view (and vice versa). Views are advantageous for the 
following reasons: 

a. They provide logical data independence. 

b. They allow the same data to be seen by different users 
in different ways at the same time. 

c. The user’s perception is simplified. 

d. Automatic security is provided for hidden data (data 

not visible thru some given view). [Ref. 2:p. 184] 
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Figure 3.2 Physical and Logical Views 



36 




These levels of architecture are an important 
consideration, and should be defined during the development 
of a database system. 

5 . Database Development Stages 

The database development process consists of four 
stages. They are: specifying the requirements, evaluating 

the alternatives, designing the database, and implementing 
the database. Specifying the requirements includes problem 
definition, feasibility assessment, and specifying detailed 
requirements. Evaluating the alternatives includes 
specifying the alternatives, and selecting one alternative. 
Designing the database includes specifying and ordering 
hardware, designing program logic, designing the data 
structures, designing the procedures for users and 
operators, and defining the user organizational structure. 
Implementing the database includes installing and testing 
new hardware, coding and unit testing programs, converting 
data, documenting procedures, training users, and testing in 
parallel. A methodology which may be used in database 

development is structured analysis (to be discussed in 
Section D of this chapter). One consideration when 
developing a database system, should be what data model the 
system is to be based on. 



37 



DATA MODELS 



C . 

1 . Definition 

Data models are how information can be represented 
and manipulated within the formal framework of a database 
system. The types of data structures which are visible to 
the user and the operations allowed on these structures are 
determined by the data model . The data model determines a 
set of possible application models (the description of the 
structures and operations in a specific system). The 
purpose and objectives of data models help to clarify why 
they are used. 

2 . Purpose and Objectives of Data Models 

The primary purpose of data models is to provide 
some formal means to represent information and some formal 
means to manipulate that representation. A data model can 
also be thought of as an abstract programming language. The 
data definition language (DDL) provides the rules (syntax) 
for declaring different variables within the database. The 
data manipulation language (DML) provides the manipulative 
operators for the data model. A database management system 
(DBMS) is merely an implementation of some specific DDL and 
DML of a data model. 

In achieving this purpose, data models must meet 
specific objectives, some of which are: 

a. To serve as a focus for database system architecture. 

b. To serve as a tool for checking the correctness of 
specific database system implementations. 
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c. To provide a basis for the development, of database 
design techniques. 

d. To provide a basis for the design of specific data 
definition languages and data manipulation languages. 

e. To allow functional requirements and performance 
requirements to be separately addressed (physical data 
independence) . 

f. To allow individual requirements and community requi- 
rements to be separately addressed ( logical data 
independence) . 

g. To provide a yardstick for the evaluation and 
comparison of specific database systems. 

h. To serve as an educational vehicle. 

i. To serve as a vehicle for research into various 

aspects of database management. [Ref. 3:p. 186] 

To satisfy these objectives, data models have been 

designed consisting of several components. 

3 . Main Components of a Data Model 

A data model generally consists of three main 
components: a collection of object types (the basic 

building blocks of the data model), a collection of 
operators (the means for manipulating the database), and a 
collection of general integrity rules (to constrain the set 
of valid states). In addition, a variety of operations are 
available in most data models. They include: 

a. Retrieval--def ining a set of data as the result of a 
query . 

b. Update--def ining a set of data to be modified or 
deleted . 

c. Defining the set of data to be accessible thru a view. 

d. Defining access rights --defining a set of data to 
which authorization can be granted. 
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e. Derining stability requirements - -def ining the scope 
of a locking operation. 

f. Defining some specific integrity const raint- -beyond 
those built into the model itself. [Ref. 3-‘p. 182] 

The three main components are found in all data 
models. The operations listed above may not be available in 
a specific data model, but may be available in the specific 
DBMS chosen. There are over thirty different data models in 
existence today. Different data models are appropriate for 
different applications. Six common data models are: the 
semantic data model, the entity-relationship model, the 
relational data model, the CODASYL DBTG model, the DBMS 
specific model, and the ANSI/X3/SPARC data model. This 
thesis will focus on the use of a semantic data model in the 
development of the database. The reason for this choice is 
that semantic data models are not dependent on any specific 
computer system or DBMS. Additionally, semantic data models 
capture more of the meaning of an application environment 
than is possible with the other data models. This is vital 
if someone else is to be able to use the model designed in 
this thesis with a specific DBMS of their choice. 

Semantic data models are logical data models in 
which the structures and operations permitted are explicitly 
meant to represent certain types of real-world information 
[Ref. 4:p. 4]. They provide a vocabulary for expressing not 
only the structure of database data, but also the meaning. 
There are some useful semantic concepts which should be 
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mentioned here. They are: an entity is a distinguishable 

object of some particular type (e.g., Personnel, Equipment, 
etc.): a property is a piece of information that describes 
an entity (e.g. , Name of SM, Number of Item’s LIN, etc. ); an 
association is a many-to-many (-to-many, etc. ) relationship 
among entities (e.g. , LIN {serial# / registration#}); a 
subtype is when entity type Y is a subtype of entity type X 
if and only if every Y is necessarily an X (e.g. , a serial# 
is a subtype of a LIN). The real world consists of entities 
that possess properties, and are connected together in 
associations. [Ref. 2:pp. 610-611] There are several types 
of semantic data models, one of which is the Semantic 
Database Model (SDM). 

4 . The Semantic Database Model 

The Semantic Database Model is a high-level, 

semantics-based database model which was developed by 

Michael Hammer and Dennis McLeod in 1981. It was designed 
to provide features for the natural modeling of database 
application environments. 

The SDM was developed with the idea of filling the 
gaps left by other database models. Some of the criteria it 
meets are as follows: 

a. The constructs of the database model should provide 
for the explicit specification of a large portion of 
the meaning of a database. 

b. A database model must support a relativist view of the 
meaning of a database, and allow the structure of a 
database to support alternative ways of looking at the 
same information. 



41 



c. A database model must support, the definition of 
schemata that are based on abstract entities. 

[Ref. 5 : p . 354] 

With these criteria in mind, SDM was developed with 
the following general principles of database organization 
underlying its design: 

a. A database is to be viewed as a collection of entities 
that correspond to the actual objects in the 
application environment. 

b. The entities in a database are organized into classes 
that are meaningful collections of entities. 

c. The classes of a database are not in general indepen- 
dent, but rather are logically related by means of 
interclass connections. 

d. Database entities and classes have attributes that 
describe their characteristics and relate them to 
other database entities. An attribute value may be 
derived from other values in the database. 

e. There are several primitive ways of defining inter- 
class connections and derived attributes, correspond- 
ing to the most common types of information redundancy 
appearing in database applications. [Ref. 5:p. 355] 

As stated in item c. above, an SDM database is a 
collection of entities that are organized into classes. The 
structure and organization of an SDM database is specified 
by an SDM schema (logical view), which identifies the 
classes in the database. [Ref. 5:p. 355] 

The following is an example of one class of an SDM 
schema for the Unit Status Reporting System: 

LIN 

description: all line item numbers for types of 

equipment the unit is authorized. 
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member attributes: 

Number_of _I tern ' s_LIN 

value class: L I NE_ I TEM_NUMBERS 

may not be null 
not changeable 
Nomenclature_of _I tern 

value class: ITEM_NAMES 

Number_of _Item’ s_NSN 

value class: NAT IONAL_STOCK_NUMBERS 

may not be null 
Quant ity_of _I tem_Required 
value class: INTEGERS 

may not be null 
Quant ity_of _I tem_Authori zed 
value class: INTEGERS 

Code_of _Item ’ s_Equipment_Category 

description: the major category of equipment 

to which the item belongs, 
value class: EQU I PMENT_CATEGORY_CODES 

Code_of _Item ’ s_Equipment_Readiness 

description: identifies whether the item is 

full, partial, or not mission 
capable . 

value class: EQUIPMENT_READINESS_CODES 

Code_of _Pacing_Item 

description: identifies whether or not the 

item is a pacing item, 
value class: PACING_ITEM_CODES 

Code_of _Item ' s_2406_Re portability 

value class: 2406_REPORTABILITY_CODES 

identif iers : 

Number_of_Item’ s_LIN 

To further clarify this example, each class in an SDM 
schema has the following features: 

a. A class name identifies the class (i.e., LIN). Each 
class name must be unique with respect to all class 
names used in a schema. 

b. The class has a collection of members: the entities 

that constitute it. Each class in an SDM schema is a 
homogenous collection of one type of entity, at an 
appropriate level of abstraction. 

c. The entities in a class may correspond to various 

kinds of objects in the application environment, 
including: concrete objects such as personnel or 

equipment on-hand; events such as date of birth; 
higher-level entities such as categorizations and 
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aggregations of entities ; names, which are syntactic 
identifiers (strings) such as the class of all 
possible item names and the class of all possible 
calendar dates. 

d. An i optional ) textual class description which 

describes the meaning and contents of the class. 

e. The class has a collection of attributes that 

describe the members of that class or the class as 
a whole. There are two types of attributes: member 

attributes describe an aspect of each member of a 
class; class attributes describe a property of a class 
taken as a whole. 

f. The class is either a base .ass (one that is defined 
independently of all other classes in the database) or 
a nonbase class (one that does not have independent 
existence because it is defined in terms of one or 
more other classes). LIN is a base class, Serial_#/ 
Regi stration_# is a nonbase class. 

g. If the class is a base class, it has an associated 
list of groups of member attributes; each of these 
groups serves as a logical key to uniquely identify 
the members of a class (identifiers). Number_of_ 
Item’s_LIN is the identifier for the LIN class. 

h. If the class is a base class, it is specified as 
either containing duplicates (the default) or not 
containing duplicates (explicitly stated). LIN 
contains duplicates. [Ref.5:pp. 356-357] 



D. STRUCTURED ANALYSIS 

1 . ftflf initjgflg 

Analysis in general is the study of a problem before 
any action is taken. More specifically, with regard to a 
system, it is the study of some area or application which 
leads to the specification of some new system. Structured 
analysis is a step-by-step approach to system development. 
The analyst begins with a logical design, and by using the 
structured approach, gradually develops a physical design. 
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The traditional analysis approach has several major problems 
which the structured analysis approach attempts to overcome. 
These problems include a lack of tools and other 
communication problems, work allocation problems, and 
politics to mention a few. In attempting to solve these 
problems, the structured analysis approach has several 
goals . 

2 . Goals of Structured Analysis 

The structured analysis approach has a number of 
well defined goals. They include: 

a. The products of structured analysis must be highly 
maintainable . 

b. The problems of size must be dealt with using an 
effective method of partitioning. 

c. Graphics have to be used wherever possible. 

d. The analyst must differentiate between the logical and 
the physical; responsibility must be allocated 
between the user and the analyst. 

e. The analyst must build a logical system model for the 
user. [Ref. 6:p. 9] 

3 . The System Life Cycle 

The structured approach to analysis is based on the 
system life cycle. This life cycle consists of seven steps: 
problem definition, feasibility study, analysis, system 
design, detailed design, implementation, and maintenance. 
The analyst moves from step to step, and must complete 
specific criteria before moving on to the next step. 
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The analysis step of the system life cycle consists 
of eight components. They are: document the current 

physical system, derive the logical equivalent, define the 
new logical system, establish the man-machine boundary, 
perform a cost/benefit analysis, select an option, develop a 
physical constraints document for the system, and package 
the structured specification. The analyst has several 

structured tools which can be used in the systems analysis 
activity . 

4 . Structured Tools 

The tools available to the analyst for structured 
analysis are: the data flow diagram (DFD), the data 

dictionary, and some method of defining the logic of the 
processes (decision trees/tables, structured English, or 
tight English). 

The first tool, the data flow diagram, is a graphic, 
partitioned, multidimensional, logical model of a system. 
The emphasis is on the flow of the data, with the flow of 
control being de-emphasized . 

The data flow diagram uses four basic symbols: a 

square or double square to indicate sources or destinations 
of data, a rounded rectangle or a circle or "bubble” to 
indicate processes which transform data, an arrow to 
indicate the flow of data, and an open-ended rectangle to 
indicate a data store (see Figure 3.3). The sources or 

destinations are external entities which are outside the 
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Sources or destinations of data 



\ 
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Processes which transform data 



Flow of data 



Data store 



Duplicate Data Store 



Figure 3.3 DFD Symbols 
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boundaries of t-he system. They are the originators or 

receivers of transactions. Processes transform incoming 

data flows into outgoing data flows. Each contains a 
description of the function it performs, and a unique 
identifying number. Data flows merely show the direction of 
flow of the data on interfaces between components of the 

DFD. A description of its contents is beside it. Data 

stores are files, temporary holders of data. Processes can 
have access to either store data, read data, or both. 

Guidelines have been developed for drawing data flow 
diagrams. Some of them are as follows: 

a. Identify the external entities involved. This invol- 
ves deciding on a preliminary system boundary. Data 

flows are created when something happens in the 
outside world that affects the system. 

b. Identify the scheduled inputs and outputs expected. 
Try to discover logical groupings. 

c. Identify the inquiries and on-demand requests for 
information. Specify one data flow that defines the 
information given to the system. Specify another data 
flow that tells what is required from the system. 

d. Take a large sheet of paper and start at the left with 
the external entity that seems to be the prime source 
of inputs. Draw data flows that arise, processes that 
ar« logically necessary, and data stores that are 
required. Don’t number the processes until the final 
draft. 

♦f* 

e. Draw the first draft freehand. 

f. Check the first draft against the list of inputs and 
outputs . 

g. Draw a clearer second draft with a minimum of crossing 
data flows. 

h. Have the user check the second draft. 
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i. Produce a lower-level explosion or each process 
defined on the second draft. Include error and 
exception handling. Produce a third draft of the top- 
level diagram. [Ref. 7:pp. 34-35] 

The second tool is the passive data dictionary which 
is data about data. It provides information about data 

flows, data stores, data structures, and data elements. 
Data flows are the paths along which the data structures 
move. Data stores are the places where data structures are 
temporarily stored. Data structures are made up of data 

elements, other data structures, or a mixture of both. Data 
elements are the smallest pieces of data, which cannot be 
decomposed any further. When describing a data element, the 
minimum amount of information to include is a name and a 
description. The name of the data element should be as 
meaningful as possible. The description briefly tells the 
meaning of the data element. Additionally, the data 
dictionary entry can include aliases for the data element, 
any related data elements, the range and meanings of values 
of the data element, the length of the data element, and 
other editing information if known. 

Data dictionaries provide seven different types of 
output. The following is a list of these outputs: 

a. An ordered listing of all entries or various classes 
with full or partial (summarized) detail. 

b. Composite reports. 

c. Cross-reference ability. 

d. Finding a name from a description. 
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e. Consistency and completeness checking. 

f. Generation of machine-readable data definitions. 

g. Extraction of data dictionary entries from existing 
programs. [Ref. 7 : pp . 63-66] 

The third tool is used to define the logic of the 
processes, by describing the structure of the logic and 
expressing policies in a complete, unambiguous way. There 
are several methods available for defining the logic. 

Decision trees are best used for logic verification 
or moderately complex decisions which result in up to ten to 
fifteen actions. They are useful for presenting the logic 
of decision tables to users. Decision tables are best used 
for problems involving complex combinations of up to five or 
six conditions. They can handle any number of actions. 
Large numbers of combinations of conditions can make 
decision tables unwieldy. Structured English is best used 
wherever the problem involves combining sequences of actions 
with decisions or loops. Tight English is best used for 
presenting moderately complex logic once the analyst is done 
so no ambiguities can arise. [Ref. 7:p. 107] 

When used together, these three tools enable the 
analyst to develop specific documentation of the system 
being analyzed. 
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E. SUMMARY 



This chapter provided an overview of the theory used to 
develop a data model for the Unit Status Reporting System. 
It included database systems, data models, and structured 
analysis . 

The next chapter will discuss the actual development of 
the database model, from specifying the requirements to 
designing the database model. 
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IV. DEVELOPMENT OF THE DATABASE MODEL 



A. INTRODUCTION 

This chapter describes the actual development of the 
database model for the Unit Status Reporting System. The 
theory presented in Chapter III forms the guidelines for the 
development, while the background information in Chapter II 
provides the data for the system to be based on. 

In presenting the development process, the chapter is 
divided into six parts which coincide with the stages of 
database development. A brief introduction precedes the 
description of the specification stage. The third part 
describes the evaluation stage, and the fourth, the design 
stage. A description of the user interface in the 
development process is followed by a short summary to 
conclude the chapter. 

B. SPECIFYING THE REQUIREMENTS 

In this first stage of the database development process, 
there are two phases. The first phase begins with problem 
definition and concludes with feasibility assessment. In 
phase two, the detailed requirements for the Unit Status 
Reporting System are specified. - 
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1 . Problem Definition and Feasibility Assessment 



The purpose of the first phase is to answer two key 
questions: what is the problem, and is there a feasible 
solution. The problem is defined in general terms at this 
time. A written statement of the objectives and the scope 
of the problem is prepared by the analyst (or database 
developer). It is critical at this point in the development 
process that the user and the developer see the problem in 
the same light, and this written statement helps assure 
this. The statement of scope and objectives is revised 
during the feasibility assessment phase, and is then 
included as part of the feasibility assessment report. An 
example is found in Appendix B. 

The feasibility assessment involves developing gross 
estimates of the costs, schedules, and technical difficulty 
of completing the project. It is a high-level, capsulized 
version of the entire process and should be relatively 
brief. Its task is only to get a sense of the scope of the 
problem, not to solve it. Users are interviewed to clarify 
the problem definition. A rough cost/benefit analysis of 
each of several possible alternative solutions should be 
done by the analyst (or database developer), and a course of 
action should be recommended. The feasibility assessment is 
found in Appendix B. Before moving on to the second phase 
of the specification stage, the user must review and approve 
what has been done so far. 
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2 . Specify Detailed Requirements 



The purpose of the second phase is to determine 
specifically what the users want the system to do. The key 
question to be answered is what must be done to solve the 
problem. Users are interviewed and their needs are defined 
and documented. This study utilized a questionnaire to aid 
in defining the user’s needs. A copy of this questionnaire 
is found in Appendix C. 

The strategy used to define and document user needs 
includes the use of data flow diagrams, a data dictionary, 
and process descriptions. Chapter III provides a detailed 
description of these three techniques. The data flow 
diagrams for the Unit Status Reporting System are found in 
Appendix D, and the data dictionary is found in Appendix E. 

Users review the documentation produced during the 
first stage for accuracy and completeness, before moving on 
to the evaluation stage of the database development process. 

C. EVALUATING THE ALTERNATIVES 

In the second stage of the database development process, 
there a*e two phases. It begins with the developer 
speci fyin* various alternatives, followed by the selection 
of one of those alternatives. The purpose of this stage is 
to determine the best approach to meet the user’s needs. 
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1 . Specifying Alternatives 



Alternative solutions are generated by looking at 
the data flow diagrams and identifying alternatives that 
will satisfy the user’s requirements. Things to consider 
are data, programs, hardware, procedures, and people. A 
more detailed evaluation should be done of all reasonable 
alternatives to help in selecting the best one. The three 
alternatives considered in this study were: to leave the 

current system as it is, to implement a file processing 
system, or to implement a database system. 

2 . Selecting One Alternative 

Once the alternatives have been identified, the best 
one must be selected. This can be done subjectively (by 



evaluating 


the 


relative 


costs and 


benefits 


of 


each 


alternative 


and 


making an 


intuitive 


decision ) 


or 


more 


objectively 


(by 


using a 


cost/benefit 


analysis ) 


or 


by a 



combination of the two. A database system was selected in 
this study because the other two alternatives proved to be 
less than adequate solutions in meeting the user’s 
requirements. A database system provides the integrated 
file processing necessary for the Unit Status Reporting 
System to be successfully implemented. Once the best 
alternative is selected, the next stage of the database 
development process (Designing the Database Model) can 
begin . 
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D. DESIGNING THE DATABASE MODEL 



In the third stage of the database development process 
there are two phases. It begins by defining the logical 
database structure, and is followed by defining physical 
database structure. The second phase (defining the physical 
database structure) is not completed in its entirety in this 
thesis. The remainder, as well as the fourth stage of the 
database development process (Implementation) are left for 
future development. 

1 . Define the Logical Database Structure 

The purpose of this phase is to specify the logical 
format of the database (to specify the database as people 
view it). This includes specifying the records to be 
maintained, their contents, and the relationships among the 
records. The Semantic Database Model (SDM) schema is used 
to document the logical database structure. The SDM was 
described in Chapter III. The system requirements which 
were defined and documented during the first stage of the 
database development process are used as the input for this 
phase of design. The SDM schema for the database model is 
found in Appendix F. Once the logical design (SDM schema) 
is completed, the user reviews the documentation to identify 
any problems found which require correction. Then the next 
phase of the design stage (defining the physical database 
structure) can begin. 
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2 . Define the Physical Database Structure 



The purpose of this phase is to transform the 
logical database structure into a physical, DBMS-dependent 
design. The SDM schema produced during the previous phase 
is used as input to this phase of design. A physical schema 
(or specification) is produced, and the user views are 
defined. In the physical schema, the content of each record 
is defined in terms of the specific DBMS being used. This 
thesis does not address this part of database design, since 
an Army-wide standard DBMS has not yet been selected. In 
defining the user views, the designer specifies which user 
groups will view which parts of the database. Views were 
described in Chapter III, and the list of user views for the 
database model is found in Appendix G. 

E. USER INTERFACE 

Throughout the development of the database model, there 
was an interface with the user to insure communication of 
user needs. Captains Mark Hiatt and Rose Haas were the key 
points of contact in the 7th Infantry Division (Light), 
Division G-4 office. During the first stage of the 
development process (Specifying the Requirements), the user 
provided input to define the problem and specify 
requirements through personal interviews and the use of a 
questionnaire (Appendix C). The questionnaire was completed 
by representative units of the 7th Infantry Division 
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(Light;. Luring the second stage of the development, process 
(Evaluating the Alternatives), the user provided input to 
the selection of an alternative through personal interviews 
and review of the documentation. During the third stage of 
the development process (Designing the Database Model), the 
user provided input to the design process by reviewing the 
logical schema and the user views. This user interface was 
integral in designing a database model to meet user needs. 
In the future, this model can be used by units in the Army 
required to submit a Unit Status Report, once they have 
access to a computer with a DBMS. 

F . SUMMARY 

This chapter outlines the design of the database model 
through the first three stages of the database development 
process: specifying the requirements, evaluating the 
alternatives, and designing the database model. It also 
identifies the user interface. The next chapter will 
present recommendations and conclusions for this study. 
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V. 



CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

The following conclusions have resulted from this study: 

1. The present Unit Status Reporting System (specifically 
the data collection and report preparation process) 
appears to have room for improvement. This is in part 
due to the dispersion of data sources throughout the 
unit, and the time consuming nature of the actual 
report preparation. 

2. Automation of the Unit Status Reporting System is 

feasible, and would require: integrated files of 

data, some direct data extraction from those files, 
and some manipulation of the already existing data in 
those files (counts and calculations). A relational 
or database system would satisfy these requirements. 
The Unit Status Report could then be generated using 
the data available in the files, except for those 
items which require the unit commander’s judgement. 

3. The ratings calculated for each individual area 

(personnel, equipment on-hand, equipment readiness, 
and training) would be suggested ratings based purely 
on the data in the database (and therefore these 
ratings would be objective). These ratings would 
still be subject to the unit commander’s judgement 
whether to upgrade, downgrade, or accept them as 
given . 

4. Additionally, a database system would provide 

flexibility for future expansion of the system to meet 
other present and potential unit record-keeping and 
reporting requirements. 

5. Implementation of a database system would result in 

such benefits as reduced time spent in report 
preparation, reduced redundancy' of data within unit 
files, reduced file size, increased data integrity, 
increased sharing of data within the unit, and 

centralized control of unit files. 

6. There are two Operations Research problems within the 

Unit Status Reporting System. They are assignment 
problems involving personnel and equipment. The 

approach taken in this thesis requires a one-to-one 
relation, and does not necessarily ensure optimal 
utilization of resources. This approach is 
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necessitated by the regulation governing the Unit 
Status Reporting System (AR 220-1), and reflects the 
system as it is currently being utilized. 



B. RECOMMENDATIONS 

The following recommendations are made, based on the 
conclusions of this study: 

1 . That the proposed model for the Unit Status Reporting 
System be implemented using the Army-wide standard 
database management system (DBMS), once it has been 
chosen . 

2. That the model be further expanded to include as many 
other unit record-keeping and reporting requirements 
as possible. This may help reduce time spent by unit 
personnel in record-keeping and report preparation. 

3. That the two Operations Research problems be further 
researched, and their solutions be incorporated into 
the model . 
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APPENDIX A- -ARMY REGULATION 220-1 



This appendix contains an extract of AR 220-1. Relevant 
sections of the regulation are included to provide an easy 
reference for the reader. The last section of the 
regulation is a glossary of terms used throughout both the 
AR, and this thesis. 
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Chapter 17 ~ ' 
GeneraJ 



r.'.rJJ 



roc*- • sa 

1*1. Purpoa#' • — - 1- < »*.*:«, 

This rcyaliDon establishes the Unit 8 Unix 
Reporting System. It explain* in detail what 
units are required to report, how reports are 
prepared, and how reports are submitted. ^ 

a. Reports submitted m accord with this 

regulaoon satisfy — * - - - 

(1) The requirements of the Army por^ 

no ns of JCS Pub 6, volume II, pan 2, chap- 
ter 1. section 6. ' ’** 

(2) Headquarters, Department of the 

Army (HQDA) needs for timely operatiooaJ 
and management inforrnaaoo. r.' m . 

b. Objectives of the Unit Sums Report- 
ing System are to provide — 

(1) The current status of U.S. Army 
units to national command authorities 
(NCAs), the Organization of the Joint 
Chiefs of Staff (OJCS), HQDA, and all 
levels of the Army chain of command. 

(2) Indicators to HQDA that — 

(a) Portray Army-wide conditions and 
trends. 

(b) Identify factors which degrade unit 

sums. * » ‘ ' 

(c) Identify the difference between cur- 
rent personnel and equipment assets in units 
and full wartime requirements. 

(d) Assist HQDA and miermediaie com- 
mands to allocate resources. '* ^ 

. . , • - > ... 

1-2. Rafarwncaa vr-w-, 

Required and related publics docs and pre- 
sen bed and referenced forms are listed in. 
appendix A. 'rv >.> * ».* - v >r* , 

s*-*- * - -vit ~rr. < -«*• w ; «< ir** **\T » 

1—3. Explanation of abbreviation* abd.! 



Abbreviaticms and spcaal terms used in this 
regulaoon are 'explained in the glossary.' 1 ^ 



1-< Rwaponsibillti** * w-.f 

a. Deputy Chief of Staff for Operation** 
and Plans (DCSOPSl The DCSOPS will— * 

( 1 ) Develop policies, standards, and prtK 

ced urea on unit status reporting.., a ' 

(2) Collect unit tutus data, make edit 

checks for accuracy, and maintain an auto- 
mated histoncaJ records file. — - • • 

(3) Ensure that OJCS is receiving 
required reports m a randy manner. '* ’f'" ~ 

(4) Process and distribute unit sutus da? 

U in a usable format to requesting Depart- 
ment of the Army (DA) agencies and 
co mmands . ... . 

(5) Establish an an soma tad methodology 

for reviewing, and analyzing unit sutus 
data. ./ •• / - 77/7 

(6) Develop and taaue guidance in tha uaa 
of trait sutua dau during coooagcncy oper- 
ations. the deliberate planning process, and 
pcxtmobtliz&Ooa. » .. 

(7) Act as focaJ paeni for tha develop- 

ment of procedure* for usmg tmrr auras da- 
ta as part of the Army Readlneit 
Management System and to improve the 
sutua of Army umta. . . . 



(3) Consider the impact on unit sutus 
when making piano Lag, programing, and 
budget decisions. 

(9) Keep the Army leadership applied 
of the surus of Army units. - • # j 

. (10) Task Army Staff agenaes and major 
Army commands (MACOMs), as appropri- 
ate, to provide supplemental data, analyses 
of unit tutus data, and recommendations 
on how to improve unit sutua levels. . . 

b. Army Staff principals, la include the 
Chief Army Reserve (CAR). Army Staff 
principals and CAR. will — 

(1) Assign specific staff responsibilities 
for monitoring and utilizing unit tunis dau 
within their area of responsibility. 

(2) Use unit turns dau to identify prob- 
lem areas and perform analyses to deter- 
mine root causes and possible solutions. 

(3) Establish and meet milestone dates 
for correcting problem areas. 

(4) Consider problems identified in Unit 
Sutus Reports and the sutus of Army units 
when developing plans and programs. . - 

(5) Assist Office of the Deputy Chief of 
Staff for Operations (ODCSOPS) in the de- 
velopment of procedures for using unit su- 
tus dau as part of Che Army Readiness 
Management System and improving the sta- 
tus of Army umta. 

( 6 ) Review unit sutus reporting guidance 

aod submit recommended changes as 
appropriate. -r^.T* t : •* „ 

c. Commanders of MACOMs and the 

Chief National Guard Bureau ( CNGB ). 
Commanders of MACOMs and CNGB 
will — * r- ■ - - 

(1) Assign specific staff responsibilities 
for supenosaoo aod coordination of the Unit 
Status Reporting System withia their, 
command w *v:r \* 

(2) Ensure that subordinate units comply 

with unit status reporting requirements, to 
include the yuhmmion.of r e p o r t * in s timely 
sad accurate manner. y 

- (3) Monitor the status of tmignrrl units, 
and analyze gad correct noted problem 
areas. - . m ) 

(4) Report trait sums conditions which 
they cannot- resolve to the appropriate 
Army Staff agency, i 

(5) Manage resources to maiimiza tha 
suras of assigned units. 

( 6 ) Consider problems identified in Unit 
Sutus Reports and the sutus of assigned 
units when devdoprag plans and programs. 

(7) In coordination with ODCSOPS, 
manage unit inactivations, activations, con- 
versions, and reorganizations to minimize 
the impact on unit sutua. 

(S) Review urn u suras reporting guidance 
and submit recommended changes ay 
appropriate. 

-(9) Commander, U.S. Army Training 
and Doctrine Command (TRADOC) will 
also— * ‘ -*«“•- - v* * " . r - “.xr?— 

(a) Use the guidelines outlined m append 
dix B to determine equipment readiness 
codes for equipment in type umu and ideur 
tify them in authonxaoon documents. — 

(b) Uae the guidcknes outlined ia appem 
dix C to determine equipment pactng items 
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for -JUU anu denary them jj suihorv- 
ZAGQt . acumen ca. ^ r 5 . 

~ . til’ ~ u 

1 - 6 . onewpt. -- ~ 

a. Designated rnndificd table of organiza- 
tion and equipment (MTOE) and tables of 
distribution and allowances (TDA) units- 
will submit recurring Unit Sutus Reports, 
requirement control symbol JCS 
6 — 11 — 2 — 1 — 6 , in accord with tables 2-1 and 

2- 2. These rep o rts determine a unit** sura* 
by comparing selected personnel, equip- 
ment, and training factors to wartime re- 
quirements and by obtaining the 
commander's overall assessment of the unit. 

(1) Unit Sutus Reports are not designed 
to measure all aspects of a unit's readiness; 
therefore, they cannot be used in isolation 
to assess unit readiness or the broader as- 
pect of Army readiness. However, these re- 
pons do provide an indication of the extent 
to which a unit can perform ts designed. 

(2) Unit Status Reports provide a timely 

single source document for assessing key el- 
ements or ) .rut’s sutus. However, these re- 
ports do ' . contain a 11 of the information 
needed to image resources. They identify 
problem areas, but in many cases these 
problems must be examined using more de- 
tailed personnel, logistic, and training ad- 
ministrative systems to determine causes 
and solutions. Reports are purposely kept 
streamlined to retain their operational 
vokty- ' . 

(3) Peacetime reporting procedures will 

vary from procedures to be used when a- 
unit. is called-up, mobilized, deployed, or 
employed as outlined in paragraphs 3-22 
and 3-23. a - ..- ” • r .-a 

-h. The Army's won suras objective is to 
develop and mainUia umu at the highest 
unit auras level possible conixienng contin- 
gency requirements and resources available. 

(1) To conserve resources, only those 

umu needed early to support contingency 
plans arc normally maintained at the high- 
est resource levels. Other units, are. 
resourced at lower levels and assigned a 
lower authorization level of organization 
(ALO). /x ' » 7 *. 

(2) No unit ia expected to attain unit su- 

tus ratinp that aioerri the level at which it 
has been provided personnel and equipment. 
Unit commanders will — - 

: (a) Maintain the highest unit status level 

possible with given resources. 

(b) Accurauly assess snd report unit 

Maras, * • • 

( c ) Distnbute unit equipment sgainst 
mission essential requiremenU (equipment 
readiness code- A) on lint priority basis. 

id) Trail to the highest level possible 
with the resources that art aviUahk, 

(3) Commanders at all levels will review 

subordinate unit rrporu and, within their 
ability, distnbutc/redisinbute resources 
available to allow subordinates to m a tunua 
tbcar status,. £'wirr*~ • w. *. 'v'n. -i# 

s k :- — - . .^01 ir.ctr 

V-fi. Unit status ratings -v-.n. 

. a Tha suras of measured resource arena 
(personnel, equipment on-hand, equipment 

3 
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